발표 스크립트: 오늘의 주제는 단순히 더 빨리 화면을 만드는 방법이 아닙니다. 업무를 가장 잘 아는 도메인 팀이 필요한 시스템을 직접 구현하면서도, 중앙 IT가 보안과 품질, 운영 통제력을 유지하는 방법을 HandStack 관점에서 살펴보겠습니다.

발표 스크립트: 비용 문제는 개발자가 코드를 늦게 작성해서만 생기지 않습니다. 도메인 지식이 전달 과정에서 빠지고, 비슷한 기술 구성을 반복하며, 작은 변경도 중앙 대기열을 거칩니다. 이 누적 비용을 줄이려면 구현 주체와 운영 구조를 함께 바꿔야 합니다.

발표 스크립트: 현업은 무엇을 만들어야 하는지 잘 알고, IT는 안전하게 만드는 방법을 압니다. 현재는 이 두 역량이 티켓과 문서를 사이에 두고 분리되어 있습니다. 로우코드 거버넌스는 개발을 현업에 떠넘기는 방식이 아니라 두 역할이 만나는 표준 경계를 만드는 일입니다.

발표 스크립트: 전통 개발은 자유롭지만 반복 구현 비용이 크고, 노코드는 빠르지만 복잡한 업무와 확장에서 제약이 생길 수 있습니다. HandStack은 표준 웹 기술과 SQL을 그대로 사용하면서 화면, 거래, 데이터 연결을 계약으로 단순화해 그 사이의 간극을 줄입니다.

발표 스크립트: HandStack의 목표는 코드를 전혀 쓰지 않는 것이 아닙니다. 업무 담당자가 이해할 수 있는 화면과 SQL, 계약에 집중하게 하고, 반복되는 연결과 실행 환경은 플랫폼이 맡습니다. 복잡한 업무가 생기면 전문 개발로 자연스럽게 확장할 수도 있습니다.

발표 스크립트: 중앙 IT는 매번 기능을 대신 만드는 조직에서 안전한 실행 기반을 제공하는 플랫폼 조직으로 이동합니다. 도메인 팀은 그 경계 안에서 업무 문제를 정의하고 구현합니다. 새로운 데이터나 외부 연계처럼 영향이 큰 지점에서만 전문 검토가 개입합니다.

발표 스크립트: 로우코드 거버넌스는 코딩 규칙만을 뜻하지 않습니다. 무엇을 왜 만드는지, 어떤 표준으로 구현하는지, 데이터는 누가 책임지는지, 어떻게 변경하고 운영할지를 함께 다뤄야 합니다. 이 다섯 영역이 연결되어야 빠른 구현이 지속 가능한 역량이 됩니다.

발표 스크립트: 화면부터 만들기 시작하면 요구사항은 계속 커집니다. 먼저 업무 문제와 소유자, 시스템이 책임질 경계와 성공 지표를 정해야 합니다. 처음에는 작은 CRUD 업무를 골라 전체 수명주기를 경험하고 실제 비용 데이터를 확보하는 편이 안전합니다.

발표 스크립트: HandStack의 ID 규칙은 파일 이름을 맞추기 위한 관례만이 아닙니다. 도메인, 화면, 거래, 실행 기능을 연결하는 공통 식별자입니다. 이 식별자를 요구사항과 테스트, 로그에도 사용하면 누가 무엇을 왜 변경했는지 추적하기 쉬워집니다.

발표 스크립트: 도메인 팀이 직접 만든다는 말이 모든 책임을 한 사람에게 준다는 뜻은 아닙니다. 업무 가치는 도메인 책임자가, 기술 경계와 위험은 전문 담당자가 판단합니다. 중요한 것은 모두가 기능, 품질, 운영이라는 같은 완료 기준을 보는 것입니다.

발표 스크립트: 모든 변경을 중앙에서 승인하면 로우코드의 속도가 사라집니다. 반대로 데이터 구조나 권한 변경까지 자율 처리하면 위험이 커집니다. 변경 유형과 영향도에 따라 검토 수준을 나누는 것이 통제된 자율성의 핵심입니다.

발표 스크립트: 도메인 팀이 직접 개발하더라도 데이터베이스에 임의로 접근하게 하지는 않습니다. 화면 요청은 transact 계약에서 인증과 입력·출력을 검증하고, dbclient나 function의 허용된 실행으로 전달합니다. 계약이 곧 자율 개발의 안전한 경계가 됩니다.

발표 스크립트: 로우코드로 구현 속도가 빨라지면 변경 횟수도 늘어납니다. 품질을 유지하려면 작은 변경, 빠른 검증, 위험도별 승인, 운영 관측의 루프가 필요합니다. 화면에서 한 번 동작한 상태가 아니라 복구와 인수인계까지 준비되어야 완료입니다.

발표 스크립트: 운영에서는 로그를 장애가 난 뒤 찾는 파일로만 보면 안 됩니다. GlobalID로 거래 흐름을 연결하면 어느 단계가 느리거나 실패하는지 볼 수 있습니다. 거래량과 사용률까지 함께 보면 유지할 시스템과 통합하거나 폐기할 시스템도 판단할 수 있습니다.

발표 스크립트: 개발 기간이 줄었다는 주장만으로는 비용 효과를 설명하기 어렵습니다. 요구사항 전달과 반복 구현, 연계, 배포, 장애, 인수인계 비용을 함께 봐야 합니다. 첫 PoC에서 기준선을 만들고 같은 지표를 도입 후에 비교하면 HandStack의 효과를 조직의 숫자로 설명할 수 있습니다.

발표 스크립트: 구매 요청처럼 범위가 분명한 업무부터 시작할 수 있습니다. 구매팀이 용어와 승인 규칙을 정하고, 화면과 거래 계약을 직접 개선합니다. 다만 금액 데이터, 승인 권한, 회계 시스템 연계는 데이터와 보안 담당자의 검토를 거칩니다.

발표 스크립트: 로우코드 도구를 많이 쓰는 것이 성숙도를 의미하지는 않습니다. 소유자와 표준이 있고, 낮은 위험의 변경은 자율 처리하며, 비용과 사용 데이터를 근거로 시스템을 통합하거나 폐기할 수 있어야 합니다. 운영 방식이 성숙도의 기준입니다.

발표 스크립트: 처음부터 전사 플랫폼을 완성하려 하지 않습니다. 소유자가 분명한 작은 업무 하나를 골라 현재 비용을 측정하고, 전체 개발과 운영 흐름을 검증합니다. 그 과정에서 만들어진 기준과 자산이 다음 업무의 시작 비용을 낮춥니다.

발표 스크립트: HandStack이 만들고자 하는 변화는 현업과 IT의 역할을 없애는 것이 아닙니다. 도메인 팀이 업무 시스템을 직접 개선하고, IT는 안전한 표준과 운영 기반을 제공하는 구조입니다. 작은 성공에서 기준과 자산을 남기고, 실제 비용과 품질을 측정하며 확장하는 것이 시작점입니다.